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Sir: 

This is an appeal from the Final rejection, dated May 12, 2006, for the above identified 
patent application. Appellant submits that this Appeal Brief is being timely filed, since 
the notice of Appeal was filed on July 12, 2006. Please charge the Appeal Brief fee of 
$500.00 to deposit account no. 08-2025. 



REAL PARTY IN INTEREST 

The real party in interest to the present application is Hewlett-Packard Development 
Company, LP, a limited partnership established under the laws of the State of Texas 
and having a principal place of business at 20555 S.H. 249 Houston, TX 77070, U.S.A. 
(hereinafter "HPDC"). HPDC is a Texas limited partnership and is a wholly-owned 
affiliate of Hewlett-Packard Company, a Delaware Corporation, headquartered in Palo 
Alto, CA. The general or managing partner of HPDC is HPQ Holdings, LLC 
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RELATED APPEALS AND INTERFERENCES 

Appellant submits that there are no other prior and pending appeals, interferences or 
judicial proceedings which may be related to, directly affect or be directly affected by or 
have a bearing on the Board's decision in the pending appeal. 

STATUS OF CLAIMS 

Claims 1-17 were presented in the present application. Claims 1-17 are the subject of 
this Appeal and are reproduced in the accompanying Claims appendix. 

STATUS OF AMENDMENTS 

No Amendment After Final Rejection has been entered. 

SUMMARY OF CLAIMED SUBJECT MATTER 

The invention described and claimed in the present application deals with Internet 
Protocoll networks and particularly with voice conferencing over such networks (p. 1, 
11. 4-5). 

Claim 1 is directed to a method for processing messages incoming on a gatekeeper 
system (300) of an Internet Protocol network, wherein the gatekeeper system includes a 
gatekeeper (320) and a plurality of sub-processes (310a-310m) each able to process a 
series of such messages, the method comprising: the gatekeeper (320) receiving 
incoming messages; and the gatekeeper dispatching received messages among the 
plurality of sub-processes (310a-310m), wherein the received messages that belong to 
the same call are dispatched to the same sub-process. (Figure 4, p. 4, 1. 9 to p. 5, 1. 21) 

Claim 11 is directed to a gatekeeper system (300) of an Internet Protocol network, the 
gatekeeper system (300) comprising a gatekeeper (320) for receiving incoming messages 
and hosting a plurality of sub-processes (310a-310m) each able to process a series of 
messages, wherein the gatekeeper (320) is adapted to dispatch the received messages 
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onto those different sub-processes (310a-310m), and further wherein the gatekeeper has 
means for identifying whether a received message belongs to a same call as a previously 
received message, and, in that case, sending this received message to the sub-process 
that processed the previously received message. (Figure 4, p. 4, 1. 9 to p. 5, 1. 21) 

Claim 13 is directed to a gatekeeper (320) in an Internet Protocol Network, the 
gatekeeper comprising means for dispatching incoming messages onto a plurality of 
sub-processes (310a-310m), the gatekeeper (320) being able to identify whether a 
received message belongs to a same call as a previously received message, and, in that 
case, being able to send this received message to the sub-process that processed said 
previously received message. (Figure 4, p. 4, 1. 9 to p. 5, 1. 21) 

Claim 15 is directed to a method for processing messages incoming on a gatekeeper 
system (300) of an Internet Protocol network, wherein the gatekeeper system (300) 
comprises a gatekeeper (320) and a plurality of sub-processes (310a-310m) each able to 
process a series of such messages, and further wherein the messages enter the 
gatekeeper (320) in an encoded form and comprise a plurality of fields, at least one of 
which contains data for identifying a call, the method comprising: the gatekeeper (320) 
receiving incoming messages; the gatekeeper decoding received message only partially, 
the decoded part including said one or several fields which contain those data (p. 7, 1. 14 
to p. 11, 1. 9); and the gatekeeper dispatching received messages among the plurality of 
sub-processes, wherein the received messages that belong to the same call are 
dispatched to the same sub-process. (Figure 4, p. 4, 1. 9 to p. 5, 1. 21) 

GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



Issue 1: Whether Claims 1-17 are patentable under 35 U.S.C. 103(a) in view of Ma, U.S. 
Patent No. 6,795,867, (hereinafter "Ma") and further in view of Brendel, U.S. Patent No. 
6,772,333, (hereinafter "Brendel")? 
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ARGUMENT 

Issue 1: Whether Claims 1-17 are patentable under 35 U.S.C. 103(a) in view of Ma, 
U.S. Patent No. 6,795,867, (hereinafter "Ma") and further in view of Brendel, U.S. 
Patent No. 6,772,333, (hereinafter "Brendel")? 

In the final Office Action of May 12, 2006, the Examiner rejects Claims 1-17 under 35 
U.S.C. 103(a) as being obvious in view of Ma and Brendel. Appellant respectfully 
disagrees. 

Appellant submits that the Examiner has not established a prima facie case of 
obviousness for the claims rejected under 35 U.S.C. §103(a). Appellant notes: 

"To establish a prima facie case of obviousness, three basic criteria must be 
met. First, there must be some suggestion or motivation, either in the 
references themselves or in the knowledge generally available to one of 
ordinary skill in the art, to modify the reference or to combine reference 
teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must 
teach or suggest all the claim limitations. The teaching or suggestion to 
make the claimed combination and the reasonable expectation of success 
must both be found in the prior art, not in applicant's disclosure" 
(emphases added) In re Vaeck, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 
1991). 

Appellant submits that the Examiner has failed to show that Ma and Brendel teach 
each and every element as claimed in the present application. 

Claim 1 

Appellant submits that Ma and Brendel do not disclose, suggest or teach, inter alia, at 
least the following features recited by Claim 1 of the present application: 
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"the gatekeeper receiving incoming messages; and the gatekeeper 
dispatching received messages among the plurality of sub-processes, 

wherein the received messages that belong to the same call are dispatched 
to the same sub-process" (emphasis added) 

The Examiner asserts that the "sub-processes" as recited in Claim 1 are disclosed by 
Ma's gatekeepers "302-306 and 352-356." See page 4, last paragraph of the final Official 
Action. The Examiner seems to further imply that the "gatekeeper" as recited in Claim 1 
are disclosed by Ma's Load Management Unit (LMA). See page 4, last paragraph of the 
final Official Action. Appellant respectfully traverses the Examiner's assertion. 

Although Ma teaches that LMUs can be either part of Ma's gatekeepers" 302-306" as 
shown in Ma's Figure 3A reproduced below, or that an LMU can be a separate entity 
from Ma's gatekeepers "352-356" as shown in Ma's Figure 3B reproduced below, 
Appellant submits that in either embodiment Ma does not disclose "the gatekeeper 
receiving incoming messages; and the gatekeeper dispatching received messages 
among the plurality of sub-processes" as recited in Claim 1. 
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FIG. 3A 
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According to Ma's Figure 4 reproduced below, to setup an IP telephony call a gateway 
sends a setup message to an assigned gatekeeper that according to the Examiner is 
allegedly the "sub-processes" as recited in Claim 1. Applicant submits that Ma's 
gateway does not disclose the "gatekeeper" as recited in Claim 1, because Ma's gateway 
does not dispatch received "incoming messages" as recited in Claim 1. According to 
Ma, the gateway receives a request from an endpoint that is trying to initiate a call. 
Upon receipt of the request from the endpoint, the gatekeeper performs initial call setup 
by sending out a setup message to the gatekeeper to try to setup the call. See column 5, 
line 63 to column 6, line 9 of Ma. 



Furthermore, upon receipt of the setup message Ma's alleged "sub-processes" passes 
the setup message to LMU wherein the LMU determines which of Ma's "sub- 
processes," i.e. gatekeepers, will service the IP telephony call. See Figure 4, steps 404 
and 406 of Ma. If LMU determines that Ma's assigned "sub-process," e. assigned 
gatekeeper, will service the IP telephony call, Ma's assigned "sub-process" will be 
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allowed to complete call setup and service the call (i.e. actually receive the incoming 
message). See Figure 4, step 408 and 416 of Ma. However, if LMU determines that a 
different servicing "sub-process," i.e. servicing gatekeeper, will service the IP telephony 
call, the assigned "sub-process" will send a Facility Redirect Message back to the 
gateway informing the gateway of the servicing "sub-process" that will handle the call 
See Figure 4, step 410 and column 8, line 64 to column 9, line 2 of Ma. Upon receipt of 
the Facility Redirect Message, the gateway sends a Release Message to the assigned 
"sub-process" and the gateway sends another setup message to the servicing "sub- 
process" wherein the servicing "sub-process" completes call setup and services the call. 
See Figure 4, steps 412-416 of Ma. 
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In view of Ma's teachings, Applicant submits that Ma does not disclose all the features 
of Claim 1. Specifically, because Ma's gateway does not dispatch the request received 
from the endpoint to the gatekeeper, but actually generates a setup message, Ma 7 s 
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gateway does not disclose the "gatekeeper" that dispatches "received messages" as 
recited in Claim 1. Furthermore, Ma teaches that it is Ma's alleged "sub-processes," i.e. 
assigned gatekeeper, that is actually receiving the incoming setup message. Therefore, 
how can Ma disclose "the gatekeeper receiving incoming messages" as recited in Claim 
1, when it is Ma's alleged "sub-processes" that is receiving the incoming messages, not 
Ma's gateway or LMU? See Figure 4, step 402 and column 8, lines 46-50 of Ma. 

Additionally, Ma's LMU does not disclose the "gatekeeper" as recited in Claim 1, 
because Ma's LMU is not capable of "dispatching received messages among the 
plurality of sub-processes" as recited in Claim 1. As shown above, if Ma's LMU 
determines that a different servicing "sub-process," i.e. servicing gatekeeper, is to 
handle the IP call, it is not the LMU that dispatching the setup message to the servicing 
"sub-process," it is the gateway that actually dispatches the setup message to the 
servicing "sub-process." See step 414 of Figure 4 below. 

Furthermore, referring to the stand-alone LMU embodiment shown in Figure 3B above 
(and by all appearances contrary to Figure 4), Ma teaches that the LMU must be able to 
accept setup messages and issue Facility redirect and release completion messages as 
appropriate. See column 8, lines 36-40 of Ma. Appellant submits that even in this 
embodiment Ma does not disclose or suggest "dispatching received messages among 
the plurality of sub-processes" as recited in Claim 1. Clearly, Ma's LMU must be able 
issue Facility Redirect Message, wherein the Facility Redirect Message is directed to the 
gateway as discussed above. Upon receipt of the Facility Redirect Message it is the 
gateway that dispatches a new setup message to another gatekeeper, not the LMU. 
Because dispatching messages among different gatekeepers is done by Ma's gateway, 
Ma does not teach, disclose or suggest "the gatekeeper dispatching received messages 
among the plurality of sub-processes" as recited in Claim 1. 
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Appellant submits that the Examiner's interpretation of Ma is based solely upon a 
hindsight reconstruction of Applicant's claims as opposed to what Ma really teaches. As 
stated by the Federal Circuit: "[i]t is impermissible to use the claimed invention as an 
instruction manual or 'template' to piece together the teachings of the prior art so that 
the claimed invention is rendered obvious. One cannot use hindsight reconstruction to 
pick and choose among isolated disclosures in the prior art to depreciate the claimed 
invention." In re Fritch, 972 F.2d 1260. Therefore, Appellant submits that the Examiner 
has failed to establish a prima facie case of obviousness for the claims rejected under 35 
U.S.C. §103(a) and Appellant respectfully requests that the rejection be withdrawn on 
appeal and Claim 1 be allowed. 

Claims 2-10 and 16 

Claims 2-10 and 16, at least based on their dependency on Claim 1, are also patentable 
over Ma and Brendel. 

Claim 11 

Appellant submits that, at least for the reasons stated above for Claim 1, Ma and 
Brendel do not teach, disclose or suggest "a gatekeeper for receiving incoming 
messages and hosting a plurality of sub-processes each able to process a series of 
messages, wherein the gatekeeper is adapted to dispatch the received messages onto 
those different sub-processes, and further wherein the gatekeeper has means for 
identifying whether a received message belongs to a same call as a previously received 
message, and, in that case, sending this received message to the sub-process that 
processed the previously received message" as recited in amended Claim 11. Hence, 
Claim 11 is patentable over Ma and Brendel and the rejection should be revered on 
appeal. 



Claim 12 
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Claim 12, at least based on its dependency on Claim 11, is also patentable over Ma and 
Brendel. 

Claim 13 

Appellant submits that, at least for the reasons stated above for Claim 1, Ma and 
Brendel do not teach, disclose or suggest "the gatekeeper comprising means for 
dispatching incoming messages onto a plurality of sub-processes, the gatekeeper being 
able to identify whether a received message belongs to a same call as a previously 
received message, and, in that case, being able to send this received message to the sub- 
process that processed said previously received message" as recited in amended Claim 
13. Hence, Claim 13 is patentable over Ma and Brendel and the rejection should be 
revered on appeal. 

Claim 14 

Claim 14, at least based on its dependency on Claim 13, is also patentable over Ma and 
Brendel. 

Claim 15 

Appellant submits that, at least for the reasons stated above for Claim 1, Ma and 
Brendel do not teach, disclose or suggest "the gatekeeper receiving incoming messages; 
the gatekeeper decoding received message only partially, the decoded part including 
said one or several fields which contain those data; and the gatekeeper dispatching 
received messages among the plurality of sub-processes, wherein the received messages 
that belong to the same call are dispatched to the same sub-process" as recited in 
amended Claim 15. Hence, Claim 15 is patentable over Ma and Brendel and the 
rejection should be revered on appeal. 



Claim 17 
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Claim 17, at least based on its dependency on Claim 15, is also patentable over Ma and 
Brendel. 



* * * 
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Conclusion 



For the extensive reasons advanced above, Appellant respectfully contends that each 
claim is patentable. Therefore, reversal of all rejections and objections is courteously 
solicited. 



The Commissioner is authorized to charge any additional fees which may be required 
or credit overpayment to deposit account no. 08-2025. In particular, if this Appeal Brief 
is not timely filed, the Commissioner is authorized to treat this response as including a 
petition to extend the time period pursuant to 37 CFR 1.136(a) requesting an extension 
of time of the number of months necessary to make this response timely filed and the 
petition fee due in connection therewith may be charged to deposit account no. 08-2025. 



I hereby certify that this correspondence is being deposited 
with the United States Post Office with sufficient postage as 
first class mail in an envelope addressed to: Mail Stop 
Appeal Brief - Patents, Commissioner for Patents, P.O. Box 
1450, Alexandria, VA 22323-1450 on 

September 8, 2006 

(Date of Mailing) 

Aileen Shrestha 

(Name of Person Mailing) 

(Signature) 

September 8, 2006 

(Date) 



Respectfully submitted, 




Attorney for Appellants 

Reg. No. 43,010 

LAD AS & PARRY 

5670 Wilshire Boulevard, Suite 2100 

Los Angeles, California 90036 

(323) 934-2300 
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1. A method for processing messages incoming on a gatekeeper system of an Internet 
Protocol network, wherein the gatekeeper system includes a gatekeeper and a plurality 
of sub-processes each able to process a series of such messages, the method comprising: 

the gatekeeper receiving incoming messages; and 

the gatekeeper dispatching received messages among the plurality of sub- 
processes, wherein the received messages that belong to the same call are dispatched to 
the same sub-process. 

2. The method of claim 1, further comprising the gatekeeper identifying whether the 
received message has the same conference identifier as a previously received message. 

3. The method of claim 1, wherein the method is executed on a H323 network. 

4. The method of claim 3, wherein the received messages to be dispatched are 
"Registration, Admission and status" (RAS) messages. 

5. The method of claim 4, further comprising identifying whether the received message 
is a registration or an admission message, and, if the received message is identified as a 
registration message, determining the sub-process to which the received message is 
going to be dispatched on the basis of the current load of the different sub-processes in 
order to balance the load of the different sub-processes. 

6. The method according to claim 4, comprising identifying whether the received 
message is a registration or an admission message, and, if the received message is an 
admission message, determining whether the received message is the first admission 
message of a call, and, in that case, determining the sub-process to which the received 
message is going to be dispatched on the basis of the current load of the different sub- 
processes in order to balance the load of the different sub-processes. 
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7. The method according to claim 1, wherein the received messages to be dispatched 
enter the gatekeeper system in an encoded form and comprise several fields, one or 
several of these fields containing data which identify a call and further wherein the 
dispatching includes decoding the received message only partially, the decoded part 
including said one or several fields which contain those data. 

8. The method according to claim 7, further comprising examining fields of the received 
message in sequence until finding said one or several fields which contain the data 
which identify the call 

9. The method of claim 8, further comprising reading one or several fields of the 
received message which indicate the type of the received message and deducing, on the 
basis of the type of the received message, a sequence of field types concerning the fields 
which are placed before said one or several fields that contain the call identifying data. 

10. The method of claim 9, further comprising examining a field which indicates 
whether some optional fields are present or not before said one or several fields which 
contain the call identifying data, in order to determine whether such optional fields 
should be found or not when examining the fields in sequence. 

11. A gatekeeper system of an Internet Protocol network, the gatekeeper system 
comprising a gatekeeper for receiving incoming messages and hosting a plurality of 
sub-processes each able to process a series of messages, wherein the gatekeeper is 
adapted to dispatch the received messages onto those different sub-processes, and 
further wherein the gatekeeper has means for identifying whether a received message 
belongs to a same call as a previously received message, and, in that case, sending this 
received message to the sub-process that processed the previously received message. 
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12. The gatekeeper system of claim 11, further comprising means to identify whether a 
received message has a same conference identifier as a previously received message, 
and, in that case, sending this message to the sub-process that processed the previously 
received message. 

13. A gatekeeper in an Internet Protocol Network, the gatekeeper comprising means for 
dispatching incoming messages onto a plurality of sub-processes, the gatekeeper being 
able to identify whether a received message belongs to a same call as a previously 
received message, and, in that case, being able to send this received message to the sub- 
process that processed said previously received message. 

14. The component of claim 13, including means to identify whether a received message 
has a same conference identifier as a previously received message and, in that case, 
sending this received message to the sub-process that processed said previously 
received message. 

15. A method for processing messages incoming on a gatekeeper system of an Internet 
Protocol network, wherein the gatekeeper system comprises a gatekeeper and a 
plurality of sub-processes each able to process a series of such messages, and further 
wherein the messages enter the gatekeeper in an encoded form and comprise a plurality 
of fields, at least one of which contains data for identifying a call, the method 
comprising: 

the gatekeeper receiving incoming messages; 

the gatekeeper decoding received message only partially, the decoded part 
including said one or several fields which contain those data; and 

the gatekeeper dispatching received messages among the plurality of sub- 
processes, wherein the received messages that belong to the same call are dispatched to 
the same sub-process. 
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16. A gatekeeper system operating in accordance with the method of claim 1. 

17. A gatekeeper system operating in accordance with the method of claim 15. 
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